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Abstract 



o 

' Concurrent systems identify systems, either software, hardware or even 

» I , biological systems, that are characterized by sets of independent actions 

' that can be executed in any order or simultaneously. Computer scien- 

tists resort to a causal terminology to describe and analyse the relations 
between the actions in these systems. However, a thorough discussion 
' about the meaning of causality in such a context has not been developed 

yet. This paper aims to fill the gap. First, the paper analyses the notion 
of causation in concurrent systems and attempts to build bridges with 
the existing philosophical literature, highlighting similarities and diver- 
, gences between them. Second, the paper analyses the use of counterfac- 

[/3 ■ tual reasoning in ex-post analysis in concurrent systems (i.e. execution 

O ' trace analysis). 



^ ' 1 Introduction 

QQ ' In the terminology of computer science, Concurrent Systems identify systems, 

CO , either software, hardware or even biological systems, where sets of activities run 

in parallel with possible occasional interactions. A simple example of concurrent 
CO . system is the Internet, which can be thought of as a set of computers, each one 

' computing its independent activity, that often communicate to exchange some 

information. A further example is the railway system of a country, where many 
trains travel sharing tracks in an ordered way so that two trains can move at 
the same time along different tracks, whereas a single track (e.g, a platform 
in a train station) can only be used by a single train at a time. Furthermore, 
5J] , the large number of activities carried on by a single human cell form a biolog- 

^ ical concurrent system, that actually shares a number of similarities with the 

Internet. 

Compared to sequential systems, where a single action is executed at a time 
according to a sequential algorithm, concurrent systems raise new complex issues 
dealing with the ordering of action executions. In particular, concurrent systems 
are characterized by sets of independent actions that can be executed in any 
order or simultaneously. As a consequence computer scientists resorted to the 
causal terminology to describe and analyse the relations between the system 
actions. However, a thorough discussion about the meaning of causality in such 
a context has not been developed yet. 

In this paper, therefore, we ask precisely what causality means and how 
causal reasoning works in concurrent systems. As we will show in the foregoing 
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discussion, causality here means quite generally dependence, whether tempo- 
ral, spacial, or even causal dependence. We will also see that counterfactual 
reasoning is indeed one of the causal tools used in concurrent systems. 

The paper is organised as follows. In section §2 we provide an introduction 
to concurrent systems, in particular we explain their formal language and oper- 
ational models through simple examples. In §3 we explain how causal relations 
are formally defined in concurrent systems and what causality means in this 
context. We also discuss this specific meaning with respect to more traditional 
debates in the philosophy of causality, for instance about production and mech- 
anisms, independence, and causation by omission. In §4 we discuss analysis 
techniques in concurrent systems, showing that counterfactual reasoning is a 
useful tool in this context. Wc provide examples of counterfactual validation 
and refutation using the theory of Nicholas Rescher. 

2 Concurrent Systems: a Crash Course 

Concurrent Systems identify systems where sets of activities run in parallel with 
possible occasional interactions. Moreover, new activities can be dynamically 
added to the system during its evolution, and terminated or aborted activities 
can be removed as well, possibly in unexpected ways. 

In computer science, a simple example of concurrent system is a network 
like Internet: it can be thought of as a set of computers, each one computing 
its independent activity, that often communicate to exchange some information 
and that unpredictably disconnect. The activities of (mobile) phones in a town, 
the railway system of a country, or else the large number of activities carried on 
by a single human cell are also concurrent systems that share similarities with 
the Internet. To illustrate, we discuss some (simple) examples. 

Railway system. Consider the simple railway system depicted below, where 
we assume that each pair of stations is connected by a single track. 

A 

/ \ 
B C 

Then consider Trainl that leaves form A, reaches B and then C, and Train2 
that leaves form A, reaches C and then B. The two trains can move concur- 
rently (possibly at different speed) to their first stop, while the transit on the 
track between B and C must be regulated so that they do not collide. In other 
words, the presence of Trainl at C depends on the previous presence of Trainl 
at B. Moreover, the usage of track AB by Trainl and track AC by Train2 are 
concurrent activities, that can take place in any order or at the same time as 
well. Finally, we say that the usage of track BC by Trainl is in conflict with 
the usage of the same track by Train2. Hence the track BC can only be trav- 
eled across either by first Trainl and then by Train2 or vice- versa, and the two 
possibilities are equally valid. That is, in absence of a fixed train scheduling, 
the choice between these two possibilities is called nondeterministic. A nonde- 
terministic choice between a set of possible alternatives is a choice that can be 
solved in different ways during different system executions. For instance, in one 
execution of the railway system first Trainl travels along BC and then Train2, 
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but in a different execution Train2 is tlie first one travelling across BC. Note 
that concurrent systems are generally nondeterministic, meaning that different 
executions of the same system may lead to different behaviours according to 
different runtime choices between nondeterministic alternatives, each of them 
equally valid even if observationally different. 



Computer network. As a further example, consider the following computer 
network, where we assume that computers exchange messages: 



NewYork 




London 



Paris 



Madrid ■ 



M oscow ■ 



Cairo 



Beijing 



Messages can travel concurrently along different links and sequentially on the 
same link. For instance, a message generated in New York can be sent to Cairo 
and at the same time a different message can be sent to Beijing travelling either 
through London or Paris. In this case the reception of the message in Beijing 
"causally" depends on the fact that it has passed through London or Paris (we 
shall discuss later what "causally" mean). Notice that such "or-causality" is not 
an issue since it might be ok to abstract from — in the sense of not knowing — 
the precise path that the message has followed, as long as we arc interested in 
relaxed properties such as "Europe might have sniffed the message in transit" 
or "Egypt has certainly have not sniffed the message" . 



Phone calls and text messages. As a final example, we distinguish from 
synchronous and asynchronous communication. On the one hand, the way two 
people talk through a phone call is a synchronous communication, that is speak- 
ing and listening happens at the same time. On the other hand, texts sent with 
mobile phones are asynchronous communications since the writer does not as- 
sume that the reading is immediate, hence he can proceed with its activity 
without waiting for the receiver to read the text. In the asynchronous scenario 
there are less "causal" dependencies than in the synchronous one. To illustrate, 
consider Alice that wants to communicate a three paragraph length letter to 
Bob. In a phone call Bob will not listen the final paragraph before he has lis- 
tened the first one. However, if Alice writes the letter to Bob by means of a 
long text, it might happen that the phone splits the long text into three texts 
of fixed length, more or less corresponding to the three paragraphs. Even if 
the three texts are sent by Alice in the right order, there are no constraints 
on the order in which the three paragraphs are received by Bob. Indeed, it is 
not a problem for Bob to first receive the final paragraph, since he eventually 
receives the remaining texts and they are properly recomposed. Hence, in an 
asynchronous system the order of reception does not depend on the order of 
sending. 

In computer science, the complexity of (concurrent) systems is addressed in a 
standard way: first the system is specified using the syntax of a precise formal 
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language; then, the system behaviour is formany described by means of a se- 
mantic operational model; finally, analysis techniques and formal reasoning are 
developed (and automated) to prove properties of such a system on top of its 
operational model. As far as concurrent systems are concerned, a number of 
formalisms have been proposed; they can be summarized as follows, according 
to three different levels of abstraction described above: 

Formal languages to specify/to program a concurrent system. Examples of 
these languages are the Java programming language, that is commonly 
used to write concurrent software, and a number of domain specific lan- 
guages targeted to the description of specific concurrent systems such as 
security protocols, concurrent hardware, system biology. Besides a rich 
number of "concrete concurrent languages" , the research on concurrent 
theory has distilled few formal languages made of a minimal number of 
primitives/connectives that capture the essential features of concurrent 
systems (Milncr. 1980, 1999). Such languages are also called process alge- 
bras to highlight the mathematical treatment of connectives like sequential 
composition, parallel composition, interaction, nondetcrministic choice. 

Operational models describing all the possible behaviours of a given concur- 
rent system (written in a formal language). Many different formalisms 
have been proposed to define such models, corresponding to different 
trade-offs between the expressivity of the model and its simplicity/abstra- 
ction power. Standard models for concurrent systems are based on the 
interleaving approach: they are based on the idea that only a single action 
can be executed at a time, according to what actually happens in a single- 
processor computer. In these models two concurrent actions A and B are 
modeled as the nondeterministic choice between executing first A and then 
B or viceversa, i.e. the arbitrary interleaving of A and B rather than their 
simultaneous occurrence. Reducing the notion of concurrency to those of 
nondeterminism and sequentiality allows us to build models that are easier 
to deal with, and has provided the basis for the development of very rich 
and elegant theories of concurrency (sec for instance Aceto ct al. (2007)). 
However, there arc properties of concurrent systems that cannot be speci- 
fied without a clear distinction between concurrency and nondeterminism. 
Then a number of non-interleaving models, a.k.a. true- concurrent models 
and sometimes causal models, have been developed by taking the notion of 
concurrency — or the complementary notion of causality — as fundamental 
(Winskcl and Nielsen, 1995). We discuss below the operational models of 
the previous examples. For the time being, it will suffice to say that an 
interleaving model of the railway system described in the previous section 
cannot model the case where Trainl is travelling across AB and at the 
same time Train2 is travelling across AC ; in such a model the two actions 
can be executed in any order but not at the same time. Instead, a true- 
concurrent model can express all the possible behaviours: Trainl travels 
before Train2, Train2 travels before Trainl, and also Trainl and Train2 
travel at the same time. 

Analysis techniques. Working with a model that explicitly talks about (ab- 
sence of) causal dependencies between the actions of the system allows for- 
mal reasoning about such dependencies. A rich toolbox of formal methods 
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have been developed to specify and automatically verify (causal) proper- 
ties of models of concurrent systems. Model checking tools, diagnosis 
methods examining the causal history of an error occurrence, behavioural 
abstractions based on the observable degree of concurrency, and specifica- 
tion temporal logics are examples of such formal analysis techniques. 

3 Causal Concepts in Concurrent Systems 

In this section we explain how 'causal relations' are defined in concurrent sys- 
tems and we discuss the meaning of causality in this context. It will emerge 
that concurrent systems are quite peculiar with respect to many other areas 
investigated in the philosophy of causality. In fact, causal relations arc defined 
and decided by the programmer, rather than discovered or established as cus- 
tomarily done by biologists, social scientists, or physicists. Causal talk may 
also appear 'loose', or even unnecessary, as causality means, in this context, 
just dependence but not production. 

3.1 Causal Relations in Concurrent Systems 

We start by looking at how the term "causality" is customarily used in the 
semantics of concurrent systems. First, since in computer science everything is 
discrete, we call event the occurrence of an action of the systems, i.e. a step 
of computation. Hence, in sequential programs, where there is a single flow 
of control at any time, causality is interpreted as space-time sequentiality of 
events. The case of concurrent systems is more complex: as anticipated above, 
for these systems there are both interleaving and true-concurrent models. We 
are now interested in the second class of models, that can express the difference 
between two actions that might simultaneously happen and two actions that can 
just be executed in any order. True concurrent models include, between others, 
Petri nets, event structures, generalized labelled transition systems and causal 
trees. Each of them comes equipped with its specific formal analysis techniques, 
but their expressivity is roughly the same (Winskcl and Nielsen, 1995), hence 
we briefly review here Prime Event Structures, which are in a sense canonical 
ad pretty accessible. 

A Labelled Prime Event Structure £ is a tuple {E, <, A) where 

• E is a set of events and A is a function that associates to each event the 
action whose occurrence that event stands for; 

• < is a partial order representing the causal relation between events. Let 
be 61,62 G E, then we write ei < 62 to state that 61 is a cause of 62. 
By deflnition of partial order, the causal relation is reflexive, i.e. e < 6, 
transitive, i.e. if 61 < 62 and 62 < 63 then ei < 63 and antisymmetric, i.e. 
if 61 < 62 and 62 < 61 then 61 = 62. When the set of events E is infinite 
(infinite computation), we assume that each event has only finitely many 
causes, i.e. causal histories arc finite. Later, we shall discuss in detail what 
"causality" means in this context. 

• ^ is an irreflexive and symmetric relation called conflict. Let be 61, 62 £ E, 
then we write 61^62 to express two alternative behaviours: either the sys- 
tem executes 61 or it executes 62, the choice between the two alternative 
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behaviours is purely nondeterministic. As an example, remember the sin- 
gle track railway system where Trainl travelling across the track BC is 
in conflict with Train2 travelling across the same track (we give below 
the complete event structure model of the railway system). There is an 
additional axiom stating that the conflict is hereditary, that is if ei is a 
cause of 62 and ei is in conflict with 63, then 62 must also be in conflict 
with 63. 

Let us first illustrate these true-concurrent models by defining the prime 
event structures associated to the examples given in Section 2. The discus- 
sion about the meaning of the causal relation introduced by event structures is 
postponed to the next subsection. 

Computer netv^rork. Wc begin by illustrating the event structure associated 
to the transmission of two messages from New York to both Beijing and Cairo 
in the computer network described above. 



66, Beijing 67, Beijing 

t t 

ei, Moscow e^, Moscow e^^, Cairo 

t f t 

e2, London e^, Paris es, Madrid 




Ci, NewYork 



In the figure "causal relations" proceed upwards following the arrows; "con- 
flict" is depicted by dotted lines. The event structure contains 9 events whose 
labels are specified besides events. The event ei (corresponding to message cre- 
ation in New York) is a cause of 62, 63, es, since in any behaviour of the system 
the event 62 (similarly for 63 and eg) cannot occur without a previous occur- 
rence of ei, namely it cannot be the case that a message is in London, Paris, 
Madrid if it was not in New York before. The events 62 and 63 are in conflict, 
accordingly, the path from New York to Beijing nondeterministically crosses 
either London or Paris. On the other hand, events 64 and 65 have the same 
label, both standing for the presence of the message in Moscow. However, they 
are kept different since they have a different causal history: 64 stands for the 
arrival of the message in Moscow travelling across London, while 65 stands for 
the arrival of the message along the alternative path. This example illustrate 
how disjoint causality is represented in event structures by duplicating events 
(with the same label but different causal histories) . Wc shall get back to disjoint 
structure later in section 3.2. 

Notice that there is a conflict also between 64 and 65 (as well as between 62 
and 65, between 63 and 64, and similarly for eg and 67), however this is a conflict 
inherited from the conflict between 62 and 63, but we do not depict inherited 
conflicts in order to keep the picture more readable. 

Finally, the events 62 and eg are not causally related nor in conflict; they are 
then said to be concurrent. Indeed, in our system it is possible that a message is 
in Madrid, travelling to Cairo, while the other message is in London travelling 
to Beijing. Notice that there are many other pairs of concurrent events, such 
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as (66,63), (69,62), (65 and 69), etc. Recall, concurrent events are independent: 
they can occur in any order and also simultaneously. 

Phone calls and text messages. Consider the two event structures corre- 
sponding to the system made of Alice and Bob, where Alice first performs the 
action Af , then talks to Bob and continues with the action A2, while Bob first 
performs the action Bf , then listens to Alice and continues with the action B2. 

B2 

t 

A2 SMS read 

SMS send 

t 

Al Bl 

The event structure in the left represents the synchronous communication 
between Alice and Bob, while the event structure in the right represents the 
asynchronous send of a text. Accordingly, only in the asynchronous case Alice 
can perform the action A2 without even waiting for Bob's completion of action 
Bl. Notice that in both cases the occurrence of Bob's B2 action depends on the 
previous occurrence of Alice's Al action, i.e. Al is in the causal history of B2. 

Railway system. The case of the single-track railway system is more com- 
plex. We can represent its causal model with the following event structure: 

A(ei) = Train 1 in track AB 
A(e2) = Train 2 in track AC 
A(e3) = Train 1 in track BC 
A(e4) = Train 2 in track BC 
A(e5) = Train 1 in track BC 
A(e6) = Train 2 in track BC 

This model illustrates which events can occur in parallel (or in any order) and 
which event must occur before another. For instance ei and 62 are concurrent, 
that is Train 1 and Train 2 can freely travel across their first track, either at the 
same time, or in any order. However, Train 2 cannot travel across BC before 
travelling across AC, represented by the dependency of, e.g., 65 on 62. Moreover, 
both events 63 and 65 represent Train 1 in track BC. They both depend on ei, 

1. e. the passage of Train 1 in track AB, but 65 also depend on 64, i.e. the passage 
of Train 2 in track BC. In other words, 63 represent Train 1 that first travels 
across track BC, while 65 represent Train 1 that travels across BC after Train 

2. The conflict between 65 and 63 models the fact that Train 1 either travels 
across BC first or second. On the other hand the conflict between 63 and 64 
models the nondeterminism of the first Train starting its travel across the track 
BC. 
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It should be clear by now that the complexity of causal models rapidly grows: 
even the behaviour of simple concurrent systems corresponds to big event struc- 
tures due to all the nondeterministic interleaving of concurrent actions and the 
duplication of events with disjoint causes. Moreover, concurrent systems usually 
have infinite behaviour (e.g. a railway system does not (should not) stop) which 
can be finitely represented by a finite set of states the system can enter infinitely 
many times. Despite such complexity, formal methods have been developed to 
automatically derive a true-concurrent model associated to a given concurrent 
program/system specified in a handy concurrent language, and further improve- 
ments are subject of current research. 

3.2 The meaning of causality in concurrent systems 

Causality as a primitive relation. The main point to notice is that in Prime 
Event Structures causality is taken to be a primitive relation: given an event 
structure £, an event A Q E is causally dependent on an event B G E ii and only 
if it has been so defined, i.e. if and only if {B,A) G <. Indeed, these models 
arc not intended to be used for causal discovery: instead of asking whether 
two events are related by a causal relation or not, which might be difiicult or 
controversial, we take causal relations as already decided, so to speak, and we 
reason on top of them. 

As we said in Section 2, a concurrent system is first specified using a formal 
syntax, then an operational model is built so that to describe all its possible 
behaviours, and finally formal analysis is conducted on top of the model in order 
to prove its properties. So, even if event structures take causal dependencies as 
primitive, the difficult problem is not completely eluded: given the system, we 
still have to associate it with a correct event structure, that is an event structure 
whose (primitive) causal dependencies agree with the system behaviour. More 
precisely, we say that a model is correct with respect to the system if any 
behaviour in the model is a plausible behaviour of the real system; we say that 
the model is also complete if any behaviour of the real system also appears in the 
model. While a model that is not correct is useless, models that are not complete 
are often useful abstractions of complex systems. Notice for instance that an 
empty model is correct with respect to any system even if it is clearly useless. 
Any other definition stating what kind of system information is represented in 
the model is somewhat arbitrary, and it is essentially justified by a proof that the 
given model is correct (i.e. any behaviour in the model is a plausible behaviour 
of the real system) and an illustration of the reasoning and predictions about 
the system allowed by that model. 

How to (automatically) associate an operational model to a given system 
is a lively research topic in computer science. While operational semantics 
based on sequential or interleaving models are pretty standard, the case of true- 
concurrent/causal models is more controversial. As an example, consider a 
software system written in the Java programming language. A naive approach 
would define a programming instruction A as dependent on an instruction B 
whenever B appears in the code before A. However, such a definition would 
lead to an incorrect model when B is the instruction "run this instruction in 
parallel with the code appearing in the following" . Moreover, the sequence of 
program instructions written by the programmer do not in general correspond 
to the sequence of instructions actually executed by the hardware: indeed the 
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runtime program execution is often defined so that to allow the reordering of 
instructions to get optimized execution performances. Rather than precisely 
modelling the reordered runtime program, the Java programming language re- 
lies on the so-called Java Memory Model (Manson et al., 2005), which defines 
a partial ordering called happens-before on all actions within a program. In 
absence of a happcns-bcforc ordering between two operations, the runtime exe- 
cution is free to reorder them as it pleases. Then in defining the causal model 
of a given Java program, the definition of the causal relation linking the pro- 
gram instructions will then agree with (but non necessarily be the same as) the 
happens-before relation defined in the specification of the Java programming 
language. Moreover, the advent of new parallel hardware (e.g. multicore CPUs 
or CPUs) have renewed the debate about the identification of the key depen- 
dencies between software instructions, leading to different memory models for 
new programming languages. 

So to summarize, the difficult problem of deciding whether two events are 
causally dependent or not is confined into the problem of correctly associating 
an event structure to a concurrent system. The definition of a correct and use- 
ful model for a given concurrent system is a lively research topic in the area of 
formal semantics. Anyway there is no causal discovery to do; the debate gener- 
ally amounts to the (somewhat arbitrary) definition of a "precedence relation" 
between system actions. 

Causality vs Dependency. The examples above show that the causal rela- 
tion < of event structures encodes any form of dependence, such as temporal 
and or spatial precedence, rather than puzzling over the causal nature of the 
link between two events. Reasoning in this way has two benefits: 

(i) Having a model that talks about causality /dependencies allows formal 
reasoning about such dependencies. For instance, we can define specifica- 
tion logics that help with proving system properties like "it is true that at 
any time an action A depends on an action B and is concurrent with an 
action C" . In the phone call and text message example above, it is true 
that Bob's action B2 depends on Alice's action Al and is concurrent with 
Alice's action A2, whereas it is not true that Alice's action A2 depends 
on the action Bl performed by Bob before reading the text sent by Alice. 
So more generally, we can say that formal reasoning about dependencies 
help prove some important properties of the system (or of the model). 

As another example of the impact of these models in formal reasoning, con- 
sider the reasoning of "reductio ad absurdum" , commonly used in maths. 
Such reasoning entails indirect proofs as "reductio ad absurdum" argu- 
ments, that derive a contradiction from a to-be-refuted false assumption. 
This proof technique also applies to the verification of concurrent systems, 
both in proving the properties of a given model and in proving the correct- 
ness of a general analysis technique. The effectiveness of indirect proofs 
comes form the fact that in the true-concurrent models described so far, 
given any pair of events A, B, the model precisely states whether they are 
causally dependent, or in confiict or concurrent. The key point is that 
there is no room for an unknown/yet-to-be-discovered link between them. 
Such a full knowledge is essential when conducting reductio ad absurdum 
arguments, since starting form a negative assumption such as "A and B 
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are not causally linked" we can still proceed in the argument by distin- 
guishing two subcases: (1) the positive assumption that A and B are in 
conflict and (2) the positive assumption that A and B are concurrent. 

(ii) The choice of encoding any dependency with the same relation rather than 
distinguishing between the natures of the dependency is particularly well 
suited to study independence of actions, which is at the core of concurrent 
systems. One of the major impacts of studying independency of actions 
is the ability to optimize the execution of a software system on top of new 
multiprocessor/multicore architectures. A single processor, or a processor 
with a single core, can only execute a single instruction per cycle, hence if 
A and B are two concurrent/independent actions, the processor can only 
perform an interleaving of A and B, that is either the sequence A and 
then B or the opposite sequence B and then A. On the other hand, if 
the processor is dual-core, A and B can be executed simultaneously. By 
correctly identifying independent actions, we can for instance compute the 
"degree of concurrency" of an application, and then estimate the maximal 
number of processors/core that application makes use of. 

It is important to observe that independence is not just the negation of 
causality. Indeed, the event structure model makes clear that two events that 
are not in the causal relation might be either independent/concurrent -i.e. they 
can occur in any order and also simultaneously — or in conflict — i.e. they can be 
both enabled but the occurrence of one disallows the occurrence of the other. 
In other terms, independence is not just non- (causal) dependence, but it is both 
non- (causal) dependence and non-conflict. We shall discuss causality and inde- 
pendence in more detail later. 

Disjunctive causality. We have mentioned that in prime event structures 
events with disjoint causes get duplicated: for instance in the Computer Network 
example above the presence of the message in Moscow is represented by two 
different events, one depending on the transit of the message through London, 
and the other one depending on the transit through Paris. As a general example, 
consider: "If Argentina or Brazil win the world cup, I'll eat my hat" . This case 
is modelled by means of two separate events: 

(i) "I eat my hat because Argentina won" and 

(ii) "I eat my hat because Brazil won" . 

Notice that the two alternative causes, "Argentina wins" and "Brazil wins" 
are mutually exclusive. Furthermore, any event depending on "me eating my 
hat" must also be duplicated, so that a copy of it depends on "me eating my 
hat because Argentina won" and a different copy depends on "me eating my 
hat because Brazil won" . 

The duplication of events corresponding to the same action with different 
causal histories guarantees an important property of prime event structures: in 
these models the causal history of any event is always fully and non-ambiguously 
known. However, such a property implies that these models cannot represent the 
so-called inclusive disjoint causality. Suppose at the beginning of the European 
Cup I say: 
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"If Germany or Italy do not reach the final, you'll eat your hat." 

If both teams don't reach the final, which one, out of the two, is the cause of 
your eating your hat? There are two possible causes (that are not mutually 
exclusive), that is "Germany does not reach the final" and "Italy does not reach 
the final" . However, from the perspective of concurrent systems, there is no 
real gain or interest in establishing which one, out of the two, is the cause. 
Notice indeed that in computer science it is often preferable to promptly rely on 
incomplete information rather than to engage space/time resources in retrieving 
complete info. It sometimes happens that even if we could in principle establish 
whether there is a dependence between two actions, we decide that it is not 
worth looking at it in more detail. 

When we are just interested in sets of possible causes we cannot rely on 
prime event structures anymore. However, generalized event structures has 
been studied by relaxing the constraint of fully knowing the causal history of 
events and by introducing some sort of incomplete information (Winskel, 1987). 
Observe, in particular, that losing a piece of information about dependencies is a 
price that we can pay when we are just interested on the concurrency properties 
of the system, that is on its independent actions. 

Summing up, encoding any form of precedence with the same relation yields 
already a very expressive model to reason about. Moreover, this is good enough, 
as long as all these kinds of dependency do not diverge/oppose, which appears 
to be the more frequent case. Also, extensions of event structures dealing with 
more than a single "causal relation" are also the object of current research. At 
this point, it is worth comparing this meaning of "causality" with the discussions 
happening in the philosophy of causality. 

3.3 A comparison with concepts from the philosophy of 
causahty 

There are a number of ways in which the meaning of causality as just discussed 
differ from the meaning discussed in the philosophy of causality. 

Production and mechanisms. In concurrent systems, while we are inter- 
ested in whether events A and B stand in a relation of dependence, we are not 
interested in other possible meanings of causality, most notably, production. One 
problem discussed in the philosophy of causality is precisely about the nature 
of the connection from the cause to the effect. The Salmon-Dowe mechanical 
model for instance, identifies production in the exchange of conserved quantities 
in physical processes (see Salmon (1984); Dowe (2000)). But this account has 
been subsequently criticised by Machamer et al. (2000) because it is not well- 
suited to biology, where the production is given by bio-chemical interactions 
that happen between entities in complex systems. In social contexts, produc- 
tion is cashed out terms of interactions between individuals, or communication, 
role of norms and values (Hedstrom and Ylikoski, 2010). 

We are not saying that events in a model cannot stay in a 'productive' 
relation, but that this is not what we are interested in establishing. We are not 
interested in whether event A causes event B in the sense of producing it, for 
instance in the sense that a virus produces flu. Likewise, we are not interested in 
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reconstructing the causal mechanism that is responsible for a phenomenon, for 
instance when we are interested in understanding the mechanisms of spread of 
an infection. We have seen that in constructing the causal model, it is sufficient 
to define a "precedence relation" between system actions. 

Preemption. Likewise, the examples about disjunctive causality just men- 
tioned have the same structure of the well-known example of 'Billy and Suzy' 
in the philosophy of causality. However, from the same conceptual structure we 
draw different conclusions. Let us explain. 

In the literature there are many variants of the example, but roughly the 
story goes like this. Billy and Suzy are playing throwing rocks at a bottle. 
Billy throws first and shatters the bottle, Suzy throws next, the rock going 
through exactly where the bottle was. So, had Billy missed the bottle, Suzy 
would have shattered it. The example shows a difficulty for the counterfactual 
theory of causality to correctly identify the cause that is responsible for an 
event. Is Suzy or not the actual cause of the shattered bottle? In fact, had 
Billy missed, she would have made it. And yet, at the same time, Suzy is just 
a preempted potential cause (for a presentation and discussion, see Hall (2004); 
Menzies (2009). 

The example certainly shows that causal assessment in natural language is 
oft undecided or unclear and that counterfactual reasoning may fail to give a 
definite answer. It does not follow, though, that in some specific disciplines 
causal relations remain undecided. In law, for instance, we can decide about 
causal assessment based on tools that complement counterfactual reasoning, 
including the whole corpus of jurisprudence or the distinction between 'causes' 
and 'conditions' (Hart and Honore, 1985). 

The majority of the (counter)examples in the philosophy of causality are 
meant to illustrate the difficulties for a specific theory or approach to unam- 
biguously identify causal relations. In concurrent systems, while we can find 
examples sharing the same structure of Billy and Suzy, they do not illustrate 
the same shortcomings. The reason is that, in this context, programmers are not 
so much interested in deciding what causes what, but what relations holds and 
do not hold in order to run a programme without bugs. Admittedly, this might 
show that the use the term 'causality' in concurrent systems is a bit overloaded 
with meaning. 

Independence. In statistical modelling and probabilistic causality, the mean- 
ing of independence is different from the one given earlier for concurrent systems. 
In these contexts independence specifically means statistical or probabilistic con- 
ditional or unconditional independence between variables of interest (Suppes, 
1970). In the approach known as 'Granger causality', independence is used to 
analyse the present state of a given variable — e.g., wealth conditions in a popu- 
lation of retired people — given the history of other, possibly related variables — 
e.g., their health conditions and the history of their wealth (Granger, 1969). In 
this way Granger tested independence: he was interested in whether informa- 
tion about past history of some variables is (or isn't) informative in order to 
determine the value of the outcome variable. Here, causality is defined through 
its negative: we say that A does not "Granger-cause" B if the history of A is 
irrelevant for B. 
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This use and meaning of independence is clearly at variance with the use 
and meaning of independence in concurrent systems, where it has to do with 
the (potentially) simultaneous execution of events in the model, which leads to 
some consequences in the evolution of the system, to be studied and analysed. 

Causation by omission. Causation by omission happens when an absence 
or a non-entity supposedly cause something. For instance, not watering the 
plant caused it to die. Philosophers worry about cases like this because it 
doesn't exist a 'metaphysical' causal link between the cause and the effect. One 
reason to insist on such a link is that often we are interested in the 'productive' 
relation between the cause and the effect. But how can a non-event such as 
non watering the plant cause its death? Possible solutions to this puzzle come 
for instance from legal theory, where a causal nexus between an omission and 
its effect can still be established, but on other grounds (e.g., legal or moral 
responsibility) (Pundik, 2007). Or from biology, where scientists notice that 
the omission of watering the plant causes its death because other mechanisms 
activate, for instance dehydration (Machamer, 2004). 

In sum, all these considerations mark an important difference between concur- 
rent systems and the philosophy of causality, where scholars by and large agree 
that causality, in various scientific contexts, involves a 'dependence' component 
and a 'productive' component (Hall, 2004; Russo and Williamson, 2007; Illari, 
2011a, b). But all this is just to say that concurrent systems seem to have 
different worry, in spite of a similarities of types of problems. 

Of course this opens the debate whether 'causality' be used improperly in 
concurrent systems. This may well be. The analysis above suggests that concur- 
rent systems may as well dispose of the term 'causality' and employ 'dependence' 
instead, without loss of content in their modelling practices. Yet, to argue for a 
reform of technical vocabulary in concurrent systems goes well beyond the goals 
of this paper. 

At the same time, the present discussion paves the way for a more thorough 
examination of causality vs dependence, not only from conceptual point of view, 
but also for applications. For instance, when the formalism of concurrent sys- 
tems is used to model biological systems, e.g. in system biology, the absence of 
a clear distinction between causality, generic dependency, precedence, necessary 
condition, leads to problems, since in biological systems the notion of causality 
certainly does not reduce to necessary conditions/precedence relation. 

We will consider already an achievement to have clarified what 'causality' 
means and how 'causal reasoning' works in this context. It will be a useful 
bridge between the philosophy of causality and scientific context that attracted 
comparatively less attention from the community. 

4 Count erf actual Reasoning in Concurrent Sys- 
tems 

We now turn to the discussion about the form of causal reasoning in concur- 
rent systems. Recall, a concurrent system may evolve in many different ways, 
and its semantic model precisely describes the (possibly infinite) set of its pos- 
sible executions. Analyzing a system amounts to study the system properties. 
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where a property is a proposition which holds true in any execution of the 
system. However, reasoning about the models of real (rather than 'toy') con- 
current systems is in general very difficult since the size of these models is huge 
and possibly unbounded. In these cases an exhaustive look at the model in 
unfeasible. Available approaches include advanced model checking techniques, 
that rely on abstractions based on behavioural equivalences or suitable tempo- 
ral logics (Clarke et al., 2001). These technique can deal with the complexity of 
concurrent systems verification. More generally, a rich toolbox of formal meth- 
ods have been developed to automatically reason about causal models, that is to 
specify and verify (causal) properties of (models of) concurrent systems. These 
analysis techniques can be partitioned into three main categories: the analysis 
conducted on the system model before the system execution (static analysis), 
the analysis conducted during the system execution (dynamic analysis, execu- 
tion profiling) and the analysis of the actual behaviour executed in a system 
run (trace analysis, fault diagnosis). 

In this section we discuss how the third class of techniques, i.e., fault di- 
agnosis or execution trace analysis, shares connections with the philosophical 
debate, namely conditionals and counterfactuals. 

We said earlier that models of real concurrent systems are huge and possibly 
unbounded, essentially because of the nondeterminism inherent to concurrent 
systems. Remind that nondeterministic executions mean that if we run the same 
program several times, its execution can be different each time. For instance, 
in the railway example, on one occasion train 1 arrives before train 2, but on a 
subsequent occasion train 2 arrives before train 1, and the system model meant 
to describe all the possible executions. 

In order to deal with such a complexity, only parts of the model are built, or 
the modelled behaviour is just an abstraction/approximation of the actual sys- 
tem execution. In particular, correct system behaviours are precisely described 
by the model, while system failures are less detailed in the model. Then, if 
during an execution something goes wrong, we need to run an ex post analysis 
to find the error in the programme. In particular we need to perform a fault 
diagnosis, that is to identify the exact system behaviour and the "cause" of the 
error. The causal model of the system then turns out to be very useful to focus 
on the specific incorrect behaviour and to reason on the chain of events that led 
to the error. Interestingly, such a process involves counterfactual reasoning. 

We will make use of the approach to counterfactuals developed by Nicholas 
Rescher (2007). We first briefiy present the theory and then illustrate how the 
theory can be applied in the validation and refutation of counterfactuals. We 
end the section with some general conclusions about the use of counterfactuals 
in concurrent systems. 

4.1 Rescher 's theory of counterfactuals 

A counterfactual is a subjunctive conditional where the antecedent is known 
or supposed to be false. Everyday language provides plenty of examples: "if I 
hadn't missed the buss, I would have been on time for class"; "had I watered 
the plant, it wouldn't have died", etc. Counterfactuals are often used to reason 
about causes and effects, in particular about what would have happened had 
the putative cause not occurred. The goal of a counterfactual is then to pick 
out the 'right' cause and we'll know that it did in case it holds true. 
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The problem, as is well known, is that it is easy to show that classical propo- 
sitional logic is not a suitable logic for giving us truth values of counterfactuals. 
In fact, if we analyse subjunctive conditionals as material implications, then we 
are bound to consider any counterfactual as true, given that the antecedent is 
false — this a consequence of the paradoxes of material implication. 

This situation led the philosopher and logician David Lewis to explore a 
different path: counterfactuals are regimented by a possible-worlds semantics 
(Lewis, 1983, 2000). Simply put, a possible-world semantics rests on the as- 
sumption of the existence of a plurality of worlds, among which there is also 
our actual world. This position is also known as modal realism. Counterfactual 
evaluation is carried out by comparing worlds with each other on the basis of 
their similarity or closeness to our actual world: the closer the world is, the more 
similar it is to the actual world. The truth of a counterfactual is then ascertained 
by an 'inspection' of what happens in other possible worlds, and according to 
the rules of counterfactual dependence as defined in the Lewis-Stalnaker seman- 
tics (Stalnaker, 1968, 1975; Lewis, 1973). 'Lewisian' counterfactuals gave rise to 
an incredibly vast literature, defending, refining, and criticising the account, to 
the point that counterfactual reasoning is usually associated with Lewis' possi- 
ble worlds approach, while alternative theories arc often neglected. One such 
theory is Nicholas Rescher's, that we present next. 

Rescher criticises Lewis' theory because of its (unnecessary) metaphysical 
baggage and also because of its practical difficulties, for instance how to get 
from one world to another or how to implement proximity between worlds. 
Rescher's account, on the contrary, is capable of making sense of counterfactual 
validation in a way that is logically precise and rigorous, and that is metaphys- 
ically parsimonious. In fact, Rescher claims his theory to be epistemic rather 
than metaphysical: while Lewis-Stalnaker invoke possible worlds and possible 
objects, Rescher invokes sets of beliefs, "which can straightforwardly, after all, be 
finite in scope, and indeed sometimes even inconsistent" (Rescher, 2007, p. 166). 

To begin with, Rescher adopts a slightly different characterisation of 'coun- 
terfactual': a counterfactual "purport [s] to elicit a consequence from an an- 
tecedent that is a belief-contradicting supposition, on evidence that it conflicts 
with the totality of what we take ourselves to know" (Rescher, 2007, p. 74). This 
definition avoids reference to events and to the truth or falsity of the antecedent. 
All is phrased in epistemic terms, appealing to beliefs and evidence. 

The formalism required by Rescher is not very heavy. He represents a coun- 
terfactual as p{B} — i> q, which is read "If p were true, which we take not to 
be so — not-p being a member of the set of our pertinent beliefs B (so that 
^p G B) — then q would be true" (Rescher, 2007, p. 81). The idea is that a coun- 
terfactual holds, or is validated, when the belief-contradicting supposition which 
is at stake will yield its consequent as a deductively valid conclusion. To perform 
the demonstration, we will have to add suitable supposition-compatible beliefs. 
The validation of a counterfactual has therefore the following generic structure: 
(disbelieved antecedent -I- certain accepted beliefs) h consequent. Rescher calls 
it a derivability construal of counterfactuals. 

The consequent q is derivable from the combination of q plus some appro- 
priately subsection of the set of background beliefs. The problem, of course, 
is to determine which beliefs to choose. These background beliefs are called 
'belief-compatible assumptions'. The choice of these assumptions is guided by a 
principle of conservation of information, namely "prioritising our beliefs in point 
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of generality of scope and fundamentality of bearing" (Rescher, 2007, p. 105). 

Counterfactual validation is then about restoring consistency in an optimal 
way by prioritising information. For instance, conceptual relations have priority 
over mere facts, norms of practice will advantage some facts over mere matters of 
brute contingency. This idea is made more precise and sophisticated by spelling 
out the acronym 'MELF'. MELF stands for Meaning, Existence, Lawfulness, 
Fact. It indicates how precedence and prioritisation work in the absence of 
case specific specifications to the contrary. The derivability of q depending on 
B (i.e. background context) is done using MELF, which guides us in choosing 
what background beliefs to use and what beliefs to discard in the derivation. 
Consider the following example borrowed from Rescher (2007, p. 106): 

"If this rubber band were made of copper, it would conduct electricity" . 

This counterfactual arises in an epistemic context where the following beliefs 
are salient: 

1. This band is made of rubber (factual belief). 

2. This band is not made of copper (factual belief). 

3. This band does not conduct electricity (factual belief). 

4. Things made of rubber do not conduct electricity (lawful belief). 

5. Things made of copper do conduct electricity (lawful belief). 

We now negate the second belief: this band is made of copper. To restore 
consistency between the initial set of beliefs, we'd have to choose whether to 
keep 3. or 5., that is between a particular feature of this band and a general 
fact about copper things. Since 5. is systematically more informative than 3., it 
has higher priority, hence we keep 5. in the background beliefs and we therefore 
accept the counterfactual. 

An important remark in using MELF is the following. While in factual 
contexts wc give priority to evidence — i.e. the most supported proposition is the 
one that is most strongly evidenced — in counterfactual contexts, we give priority 
to 'fundamentality' (rather than cvidcntiation) — i.e. aspects about meaning, 
existence, and lawfulness. 

For the interested reader, Rescher (2007, ch.ll) book provides more technical 
details on the logics to be used for MELF considerations in derivability; in 
particular, Rescher discusses the inductive character of his derivability construal, 
and also other important properties such as monotonicity and transitivity (it is 
non-monotonic and transitivity fails). 

With this theoretical background, we can now illustrate counterfactual reasoning 
at work in a concurrent systems example. 

4.2 Application of counterfactual reasoning in concurrent 
systems 

We illustrate counterfactual reasoning taking inspiration from a real case. Rover 
on Mars. A precise account of what happened to Mars Pathfinder is out of our 
scope. We just describe here an example containing an erroneous behaviour 
with the aim of illustrating counterfactual reasoning over causal models. The 
real case is documented in Jones (2007) These are the salient facts: 
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Rover on Mars. On the 4th July 1997 the Mars Pathfinder bounced onto 
the Martian surface surrounded by airbags. After landing, it deployed the So- 
journer rover which started gathering and transmitting voluminous data back 
to the Earth. But a few days into the mission, the spacecraft began experi- 
encing system resets. After the failure, NASA engineers spent hours and hours 
running the system on the exact spacecraft replica in their laboratory, attempt- 
ing to replicate the precise conditions under which they believed that the reset 
occurred. When they finally reproduced a system reset on the replica, the anal- 
ysis of the computation trace revealed a well known concurrency bug, a so-called 
priority inversion problem. 

The essence of the Mars Pathfinder experience can be illustrated in terms of 
counterfactual reasoning on top of the concurrency models discussed in previous 
sections. The software system controlling the Sojourner rover is a concurrent 
system that carries out and coordinates a number of parallel activities. For the 
sake of simplicity we can assume that the following event structure is a (minimal) 
portion of the whole operational model describing the rover's behaviour: 

p ^ X{A) — Take landscape pictures 

\ y X{B) = Move the rover 

\ / \{C) = Communicate with the Earth 

^ ^ X{D) = Inspect a specific object 

\ "■>^-....\ A(S) = Error 

A B A(F) = Ok 

The model shows that initially the rover can move (event B) and at the same 
time it can take pictures (event A). We can think the event D as the rover 
inspecting a specific object that had been previously identified in a picture and 
after the rover have moved next to it, i.e. D "causally depends" on both A 
and B. Moreover, the model specifies that moving the rover (event B) is in 
conflict with a communication with the Earth (event C) , which means that the 
execution of B prevents the execution of C, and viceversa. Therefore, even if 
initial independent actions A and B could be in principle executed in any order 
or even concurrently, different choices in their execution order have different 
impacts on the possibility of executing C. Finally, the model shows that after a 
communication with the Earth, the system enters either a correct state F or an 
error state E. Let suppose that such a choice depends on the presence of light 
on the Martian surface: if after a communication with the Earth the rover is in 
the darkness, then it enters an error state. 

Let assume that this event structure is a correct model for the Sojourner 
rover, that is all the behaviours in the event structure arc plausible rover's 
behaviours. Than the correctness of the model shows that the system itself is 
not correct: indeed, a system is said to be correct whenever no system run can 
end up in an error state, which is clearly not the case of the rover. Notice that 
such a situation is not so odd: the entire model of the rover system has millions 
of states, hence it is usually unfeasible to generate (and inspect) the whole 
model. Instead, only parts of the model are built up, or it is generated only 
an approximation of the concrete model, taking into account the risk of leaving 
unnoticed an error state, typically hidden in an infrequent system behaviour. 
That's exactly what happened to the Mars Pathfinder: the engineers did not 
realize the system error and sent the rover to Mars. 

Once activated on the Martian surface, the system started to run according 
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to its model. There were three initial possibilities: executing A, or executing B, 
or executing both A and B concurrently. The rover on Mars executed A. After 
that, the rover could choose to execute either B ot C; it executed C and then 
moved to the error state E since the rover found itself into the darkness. 

Wc now distinguish two types of use of countcrf actuals: validation and refuta- 
tion. 

Counterfactual validation. The precise sequence of actions performed by 
the rover was not known by the NASA engineers on the Earth. They only 
new that the rover had started its execution according to the installed soft- 
ware, meaning that it was executing one of the possible behaviours they had 
programmed. It has been reported that after the unexpected failure, the engi- 
neers "spent hours and hours running the system on the exact spacecraft replica 
in their laboratory, attempting to replicate the precise conditions under which 
they believed that the reset occurred" . This can be rephrased in our example as 
the engineers setting out all the possible behaviours in the system model until 
they found a behaviour ending up in the error state reported by the rover. Their 
explanation of the problem could then be stated as the following counterfactual: 

"Since it was dark, if the first rover's action had been _B, 
it would not have entered the error state." 
Now, using Rescher's MELF theory, our beliefs are as follows: 

1. It was dark. 

2. The rover did not perform B as its first action. 

3. The rover performed C. 

4. The rover ended up in E. 

5. The execution of B prevents the execution of C. 

6. If E is executed, then it is dark and C has been previously executed. 

where 1-4 are "Facts", while 5-6 are "Laws". In order to validate the coun- 
terfactual let assume not-2, then 3 and 5 become incompatible. MELF theory 
prioritizes the lawful 5 over the merely factual 3. We then retain 5, which is 
however incompatible with 4-1-6 Again we reject the weaker factual 4 obtain- 
ing the desired conclusion. Notice that wc could have used a slightly different 
belief: (5bis) The execution of B prevents the execution of E. This choice 
leads to a simpler counterfactual validation: assume not-2, then 5bis and 4 are 
incompatible, and 4 must be rejected since it has lower precedence. 

As a further example, given the actual rover execution, consider the following 
counterfactual: 

"If there had been light, the rover would not have 
entered the error state." 

Notice that the "cause" of the rover error is not (just) the darkness, but (also) 
the fact that, after A, in the choice between executing B or C, the rover executed 
C. In other terms, even if there had not been light (which was indeed the case), 
the rover could not have entered the error state. Anyway, this counterfactual is 
valid. Indeed, consider the following beliefs: 
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1. It was dark. 

2. The rover ended up in E. 

3. If S is executed, then it is dark. 

Assuming not-1 wc have that 2 and 3 become incompatible, and the factual 
2 must be rejected in favour of the lawful 3 The dismissal of 2 proves the 
counterfactual. 

The puzzling thing behind this counterfactual is that the cause of the event 
E is twofold (i.e., the darkness and the occurrence of C instead of B) while the 
assumption of the counterfactual just falsifies a single cause. The counterfactual 
validity then comes since a conjunction can be negated by just negating one of 
its operands. The dual case, that is disjunction, is more delicate, and has rather 
to do with counterfactual refutation, which wc discuss next. 

Counterfactual refutation. Let now assume that the actual rover execution 
on the Martian surface had been the following, which is still consistent with the 
model above: first B, then A and finally D, everything in the darkness. Let 
consider the following counterfactual: 

"If the first rover action had been A, it would have 
ended up in the error state." 

We know that this counterfactual is false since, even if the sequence starts with 
A, the Rover still has to choose between B and C, and only choosing C would 
lead to an error. 

In order to show how to precisely refute this counterfactual according to 
Resher's theory, we first discuss the following example, taken form Rescher 
(2007, p. 123): consider the following two counterfactuals 

(CI) If Napoleon were Julius Caesar, then Napoleon would be dead by 100 CE 
(since Caesar was). 

(C2) If Napoleon were Julius Caesar, then Caesar would be alive in 1800 CE 
(since Napoleon was). 

These two conditionals seem innocuous when taken separately, but they are not 
cotenable since they constitute an inconsistently conflicting pair. Indeed, using 
MELF approach, they cannot be validated: consider the following beliefs 

1. Caesar was dead by 100 CE. 

2. Napoleon was alive in 1800 CE. 

3. If X=Y, then whatever holds of X will hold of Y. 

4. Napoleon is not Caesar 

Let assume not-4. Then Bl={not-4, 3, 2} is a consistent subset of beliefs which 
gives "Caesar was alive in 1800 CE", while B2={not-4, 3, 1} is a different 
subset of beliefs which gives "Napoleon was dead by 100 BC" . Rescher's MELF 
theory requires the consequence to be obtained from every consistent subsets of 
beliefs. So (CI) cannot be validated since "Napoleon was dead in 100 CE" is only 
obtained from B2 whereas form Bl (actually from 2) we have that "Napoleon 
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was not dead in 100 CE" (since he was alive in 1800 CE). Similarly (C2) can be 
obtained from Bl while B2 proves its denial. Notice that the only counterfactual 
we can validate is 

(C3) If Napoleon were Julius Caesar, then either Napoleon would be dead by 
100 CE or Caesar would be alive in 1800 CE. 

Coming back to the rover example, the valid couterfactual is 

"If the first rover action had been A, it would have 
end up either in error or in the correct state D" . 

More precisely, for any set of beliefs, we have a (salient) law stating that after 
A the rover can execute either C (leading to the error) or B (preventing the 
error). The presence of such a disjunction actually prevents the validation of 
the original counterfactual. Notice also that this very same argument prevents 
the validation of its denial, that is "If the first rover action had been A, it 
would not have end up in the error state." Anyway, how do we prove that a 
counterfactual is false in MELF theory? Recsher only seems to refer to proving 
the counterfactual negation or denial, but we have seen that it might not always 
be possible. On the other hand, since a counterfactual C must be verified in 
every consistent subset of (salient) beliefs, in order to reject it it is sufficient to 
show a consistent subset of beliefs that implies the denial of C. Notice that it is 
still different from validating the denial, which would indeed require a proof of 
the denial for every subsets of beliefs rather than for just one. 

In other words, proving a counterfactual amounts to deal with a universal 
quantifier (i.e., validate it for every consistent subset of beliefs), while to refute 
a counterfactual we only have to deal with an existential quantifier (i.e., show 
a consistent subset of beliefs that implies the denial). For instance, in the 
Napoleon- Caesar example above, the subset Bl, respectively B2, can be used to 
prove that the counterfactual (CI), respectively (C2), is false. Interestingly, in 
concurrent systems, operational models offer a very effective way to prove that 
a counterfactual is false: indeed it is sufficient to show a specific behaviour that 
is allowed by the model and where the counterfactual is false. The behaviour A, 
then B then D is indeed a plausible behaviour that refutes the counterfactual, 
while the behaviour A then C then is a plausible behaviour that refutes the 
counterfactual's denial. 

4.3 Philosophical morals 

Before closing this section, we draw some general morals about the use of coun- 
terfactual reasoning in concurrent systems using Rescher's approach. 

Rescher's account is versatile and well fits the needs of counterfactual reason- 
ing in concurrent systems. More precisely, in Rescher's theory we can distinguish 
between different types of belief, on the other hand using operational models 
we can rely on simplified distinction just between 'facts' and 'laws'. In particu- 
lar, 'facts' correspond to assertions such as "event E occurred" or "event E did 
not occurred", and 'laws' correspond to the relations between events as they 
are described in the model, e.g. "A and B are independent / dependent / in 
conflict" (these relations can be written as implications between occurrences of 
events) . Such a clear distinction is important because we have that using these 
models in the derivation of the proof of a counterfactual we can always decide 
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the priority of beliefs. This is clearly at variance with Lewis' theory, where the 
similarity between possible worlds is taken as primitive and the criteria to order 
worlds according to their similarity remains an open problem in the approach. 

Being able to use 'laws' in the proofs is an advantage also for the following 
reason. Given the nature of the model, for each couple of events, it is known 
what relation they stand in, as the programmer decides about such relations. 
Consequently, all the 'laws' connecting all the couple of events are known from 
the model. Counterfactuals can then be validated by combining salient laws 
into a well-constructed proof. Conversely, given that the model describes all the 
possible system executions, a counterfactual can be rejected by showing a case, 
namely one possible execution that violates the counterfactual. 

5 Conclusion 

We presented an account of causality in an important field of computer science, 
that is the modelling of concurrent systems. These systems, cither software, 
hardware or even biological systems, can be thought of as sets of activities that 
run in parallel with possible occasional interactions. 

The formalization of concurrent systems is an interesting area to investigate 
the meaning and use of causal concepts. One reason is that these systems have 
important practical applications since concurrent software systems and parallel 
hardware are pervasive. Another reason is that the literature in computer sci- 
ence customarily use causal terms, but a systematic investigation has not been 
carried out so far. 

We first provided a crash course in concurrent systems to set the ground for 
a discussion of the meaning and use of causal concepts therein. One result is 
that the use of the term 'cause' or 'causality' in this area is perhaps not fully 
justified, as it could be replaced with 'dependence' or 'precedence' with no loss of 
content or informativity. In fact, 'causality' or 'dependence' denote an ordering 
between event occurrences. But there is nothing, in such a characterization, 
which is specifically causal, in the sense that causes produce their effects. 

An important feature of causal reasoning in concurrent systems is the use 
of counterfactuals. We examine how counterfactuals are used in concurrent 
systems and we illustrate applications using Nicholas Rescher's theory. This 
also marks a difference with the philosophical literature, that mainly focused on 
Lewis' account better-known account based on possible-world semantics. 

So there are a number of ways in which the use of causal terms in concurrent 
systems distances itself from the traditional 'hot' topics in the philosophy of 
causality: production, mechanisms, causation by omission. Yet, our goal in 
the paper is not to call for a terminological change in the field of concurrent 
systems. We think that at this stage a rounded discussion about similarities and 
dissimilarities with parallel debates happening in the philosophy of causality is 
already a contribution. 
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